A split-architecture network design introduces a separation between the control and forwarding components of the network, also referred to as the control plane and the forwarding or data plane. Split architecture networks can be utilized in an access/aggregation domain of a carrier-grade network, a mobile backhaul, cloud computing, and multilayer (L3 & L2 & L1, optical transport network (OTN), wavelength division multiplexing (WDM)) support, all of which are among the building blocks of the network architecture.
Unlike the traditional network architecture, which integrates both forwarding (data) and control planes in the same box, split architecture decouples these two functions and runs the control plane on servers (controllers) that might be in different physical locations from the forwarding elements (switches). The split architecture simplifies the functions and hardware of the forwarding platform and concentrates the network's intelligence and management into a set of controllers that oversee the switches. The tight coupling of forwarding and control planes in the traditional network architecture usually results in a highly complicated control plane and complex network management. This makes creation of new networking devices expensive and creates a high barrier to entry for new protocols and technology for potential deployment in these devices. Despite the rapid improvement on line speeds, port densities, and performance, the network control plane mechanisms for managing these features have advanced at a much slower pace.
In a split architecture network, controllers collect information from switches, and compute and distribute the appropriate forwarding decisions to switches. Controllers and switches use a control plane protocol to communicate and exchange information. An example of such protocol is OpenFlow, which provides an open and standard method for a switch to communicate with a controller. FIG. 1 is a diagram of an overview of the OpenFlow interface between a switch and a controller. The OpenFlow controller communicates with the OpenFlow switch using a secure channel to configure a forwarding table (flow table).
The forwarding table in an OpenFlow switch is populated with entries consisting of: rules defining matches for fields in packet headers; actions to be executed upon detecting a match defined by a rule; and a collection of statistics on the processing of data packets in the data plane. When an incoming data packet matches a particular rule, the associated actions are performed on the data packet. A rule contains key fields from several headers in the protocol stack, for example Ethernet MAC addresses, IP address, IP protocol, TCP/UDP port numbers as well as the incoming port number. A set of data packets having similar characteristics can be managed as a flow. A flow can be defined using any number or combination of the available fields in a data packet. It is also possible to restrict the rules to match on a subset of the available fields by using wildcards for the unwanted fields.
The de-coupling of the control plane and data plane of the split architecture eases the task of modifying the network control logic and provides a programmatic interface upon which developers can build a wide variety of new protocols and management applications. In this model, the data and control planes can evolve and scale independently, while the cost of the data plane elements is reduced.